The widespread emergence of the Internet has led to a number of popular online content repositories. An online content repository typically functions as a web-based service that allows users to access and download different types of content. Some of the most compelling content comprises full motion video files. The video files include, for example, clips of television programs, home made video produced via camcorder, cell phone, or the like. Additional examples include professionally produced downloadable movies from commercial web sites, such as, for example, XboxLive™, Netflix™, and the like. The video content can be stored at the repository solely for download. Alternatively, some repositories specialize is allowing users to upload content for sharing.
The common attribute among the video files is their typically large size. For example, a single jpg image can be considered large at 2 to 3 Mbits. In comparison, a DVD quality clip includes 30 frames of 640 by 480 ixels per frame, per second, for approximately 4 Mbits/s to 6 Mbits/s. Thus, large amounts of bandwidth is needed to download video content. The bandwidth requirements are especially problematic when video is downloaded for real time playback. Many megabits per second of bandwidth is needed for good quality real time video playback.
Thus, many conventional schemes have tried to overcome the bandwidth limitations inherent in network based video playback applications. The typical mechanism they use is compression. One solution involves selecting a compression rate that fits the bandwidth conditions of a given link. For example, a cable modem user is typically able to down load higher bit rate content for higher quality video playback in comparison to a DSL user. Because of this, the cable modem user can download content that is encoded at a higher bit rate than the DSL user. Generally, higher bit rate encoding leads to better quality video. This solution can be somewhat effective so long as the network conditions are comparatively constant.
However, network conditions are notoriously variable. In actual use, many different factors impact the bandwidth a user actually experiences. Such factors include contention among many different users accessing the same communications link (e.g., the same coaxial cable), the contention among many different users transmitting across the same wireless frequency, and the like.
Thus, companies that specialize in streaming video over networks need to accommodate the variable transmission conditions. One conventional mechanism involves the video server using a large number of duplicated chunks of a given video clip, where each chunk corresponds to a small time period of the video clip. For example, a 30 minute video clip can be chopped up into 600 five second chunks, each chunk being a specific time period of the clip. Each of these chunks are then replicated a number of times, each time at a different bit rate. Then, as the video is playing, the playback application can determine the network conditions are clogging up the playback. If the available bandwidth is insufficient, the next chunk is requested at the lower bitrate. If additional bandwidth is available, the next chunk is requested at the higher bitrate.
There exists a problem, however, in that in order to make the transitions between the chunks function, each of the chunks need to be “wrapped” in a significant amount of metadata. This metadata is needed by the conventional player to facilitate the assembly and play back of the clip when shifting between different bit rates. Additionally, on the user's machine, a significant amount of processing power is needed to interpret the metadata, strip the metadata out of the video stream, and then decode the video stream itself
A significant amount of preprocessing is needed to transform the original video clip into a chunked version, and then replicate the chunks to implement different bit rates. Furthermore, the preprocessing typically forces the inclusion of many artificial cut points to facilitate the bit rate changes. These cut points significantly hurt the low bitrate files. The added cut points increase their overall size by a significant percentage.
Another problem is the fact that complex tools are needed to produce the different versions of the highly chunked video file. These tools are designed for professionals, and although they may provide an end-to-end solution, they are not user-friendly enough or compatible enough to be used by everyday consumers.
Yet another problem is the fact that the output of the preprocessing (e.g., the different versions of the highly chunked video file) is essentially unplayable by anything but a matching highly specialized player that is specifically tuned to interpret the metadata wrappers. The preprocessing takes a nominally readable video file and turns it into the highly chunked version of the video file that is essentially unreadable. A matching, specifically engineered and specialized, player is needed to interpret the chunked video file and properly play it back. Additionally, a considerable tracking burden is imposed through the complexity of managing the numerous chunks created by the preprocessing.